The monitoring and administration of implantable medical devices (IMDs) may be well-suited to computerized and networked administration. The modern IMD is capable of sensing and storing large amounts of physiologic data from the host patient, and is also capable of implementing a treatment regimen based at least in part on this data—IMDs themselves naturally contain a powerful processing capacity in their own right. In addition, remote administration of IMDs via networks or other telecommunications media is being developed, and various IMD systems enable remote administration, such as those patient management and chronic systems as illustrated and described in applications assigned to the assignee of record entitled “System and Method for Transferring Information Relating to an Implantable Medical Device to a Remote Location,” filed on Jul. 21, 1999, Ser. No. 09/358,081; “Apparatus and Method for Remote Troubleshooting, Maintenance and Upgrade of Implantable Device Systems,” filed on Oct. 26, 1999, Ser. No. 09/426,741; “Tactile Feedback for Indicating Validity of Communication Link with an Implantable Medical Device,” filed Oct. 29, 1999, Ser. No. 09/430,708; “Apparatus and Method for Automated Invoicing of Medical Device Systems,” filed Oct. 29, 1999, Ser. No. 09/430,208; “Apparatus and Method for Remote Self-Identification of Components in Medical Device Systems,” filed Oct. 29, 1999, Ser. No. 09/429,956; “Apparatus and Method to Automate Remote Software Updates of Medical Device Systems,” filed Oct. 29, 1999, Ser. No. 09/429,960; “Method and Apparatus to Secure Data Transfer From Medical Device Systems,” filed Nov. 2, 1999, Ser. No. 09/431,881; “Implantable Medical Device Programming Apparatus Having An Auxiliary Component Storage Compartment,” filed Nov. 4, 1999, Ser. No. 09/433,477; “Remote Delivery Of Software-Based Training For Implantable Medical Device Systems,” filed Nov. 10, 1999, Ser. No. 09/437,615; “Medical System Having Improved Telemetry,” filed Jul. 19, 1999, Ser. No. 09/356,340, now U.S. Pat. No. 6,298,271; “Apparatus and Method for Remote Therapy and Diagnosis in Medical Devices Via Interface Systems,” filed Dec. 14, 1999, Ser. No. 09/460,580; “Virtual Remote Monitor, Alert, Diagnostics and Programming For Implantable Medical Device Systems” filed Dec. 17, 1999, Ser. No. 09/466,284; “System Of Notification Of Recalled Components For A Medical Device” filed Dec. 29, 1999, Ser. No. 09/474,694; “A Communications System For An Implantable Device And A Drug Dispenser” Dec. 30, 1999, Ser. No. 09/475,709; “Instrumentation and Software for Remote Monitoring and Programming of Implantable Medical Devices (IMDs), filed Dec. 20, 2000, Ser. No. 09/745,112; “An Information Network Scheme For Interrogation Of Implantable Medical Devices (IMDs),” filed Dec. 18, 2000, Ser. No. 09/740,128; “Medical Device GUI For Cardiac Electrophysiology Display And Data Communications,” filed Dec. 21, 2000, Ser. No. 09/746,230; “Integrated Software System For Implantable Medical Device Installation And Management,” filed Dec. 18, 2000, Ser. No. 09/740,078; “Dynamic Bandwidth Monitor And Adjuster For Remote Communications With A Medical Device,” filed Dec. 20, 2000, Ser. No. 09/745,143; “Large-Scale Processing Loop For Implantable Medical Devices (IMDs),” filed Dec. 18, 2000, Ser. No. 09/740,080; “A Method And System For Using Implanted Medical Device Data For Accessing Therapies,” filed Dec. 18, 2000, Ser. No. 09/740,127; “Automatic Voice and Data Recognition For Medical Device Instrument Systems,” filed Dec. 6, 2000, Ser. No. 09/731,178; “Central Network to Facilitate Remote Collaboration With Medical Instruments,” filed Dec. 20, 2000, Ser. No. 09/745,038; “Method And A System For Conducting Failure Mode Recovery In An Implanted Medical Device,” filed Dec. 6,2000, Ser. No. 09/731,222; “User Authentication In Medical Systems Device,” filed Dec. 29, 2000, Ser. No. 09/750,739; “Apparatus and Method For Automated Invoicing Of Medical Device Systems,” filed Oct. 29, 1999, Ser. No. 60/173,824; “Responsive Manufacturing and Inventory Control,” filed Feb. 1, 2001, Ser. No. 09/775,281; “Information Remote Monitor (IRM) Medical Device.” filed Feb. 2, 2001, Ser. No. 09/776,265; “Follow-Up Monitoring Method And System For Implantable Medical Devices,” filed Dec. 8, 2000, Ser. No. 09/732,951; “An Implantable Medical Device With Multi-Vector Sensing Electrodes,” filed Mar. 1, 2001, Ser. No. 09/797,031; “Stimulator For Delivery Of Molecular Therapy,” filed Mar. 5, 2001, Ser. No. 09/799,304; “Individualized, Integrated, And Informative Internet Portal For Holistic Management of Patients With Implantable Devices,” filed Mar. 15, 2001, Ser. No. 09/809,983; “Heart Failure Monitor Quick Look Summary For Patient Management Systems,” filed Mar. 16, 2001, Ser. No. 09/809,915; “A Universal Interface For Medical Device Data Management,” filed Mar. 16, 2001, Ser. No. 09/809,914; “System and Method For Providing Remote Expert Communications And Video Capabilities For Use During A Medical Procedure,” filed Mar. 24,2000, Ser. No. 09/815,728; “A Hand-Held Surface ECG and RF Apparatus incorporated With a Medical Device,” filed Mar. 29, 2001, Ser. No. 09/821,201; “Variable Encryption Scheme For Data Transfer Between Medical Devices And Related Data Management Systems,” filed Mar. 30, 2001, Ser. No,. 09/821,518, “Implantable Medical Device Controlled ByA Non-Invasive Physiological Data Measurement Device,” filed Apr. 4,2001, Ser. No. 09/825,909; “Method and Apparatus For Communicating With Medical Device Systems,” filed Oct. 25, 2000, Ser. No. 09/696,319; “Passive Data Collection System From A Fleet Of Medical Instruments,” filed Apr. 19, 2001, Ser. No. 09/838,697; “Report Configuration, Formatting and Distribution For Implantable Medical Devices And Instruments Network Systems,” filed Apr. 21, 2000, Ser. No. 60/198,973, now abandoned; “Interface Devices For Instruments In Communication With Implantable Medical Devices,” filed Apr. 19, 2001, Ser. No. 09/838,696; “GUI Coding for Identification of Displayable Data Quality From Medical Devices,” filed Apr. 24, 2001, Ser. No. 09/841,261; all of which applications are incorporated herein by reference in Their entirety. Networked and computerized IMD administration systems, based as they are on a distributed computerized environment pose numerous challenges in the development of software in the implementation or maintenance of such systems. The constituent processors of an IMD management system, for example, exist in numerous patients at the IMD level, and in an equally large number of residential and clinical settings, all of which are being modified, replaced, and upgraded at various times according to the needs of the patients and clinicians using the system at any given time. The administration of such a network is complicated further by the fact that the software implementing the network may be developed in a dispersed fashion—various IMDs, peripheral devices and monitoring equipment, and clinician and administrative computer environments may be developed in a way that is suitable for the task at hand, but may be without particular regard to other possible uses of the software, or the other network nodes with which the software must communicate. The resulting overall network may be implemented in an atomized, fragmented manner. In addition, the distributed nature of various IMD administration processes may limit the ability of remote users to effect the IMD-related function that is desired at the appropriate time. For example, a user desiring a physiological report regarding a patient may only be able to view such a report if they have direct access to an IMD programmer that has been programmed with The ability to generate reports.
Component-based software technology provides means for defining and using software components. Component technology, as implemented in evolving standards such as CORBA, DCOM and Enterprise Java Beans (EJB), provide the means for defining and using software components. The techniques of software component technology provide superior ways of developing and administering software.
Component technology is related to the developing object technology, which uses class-based software architecture to enable distributed and reusable programming. Under object technology, rather than a monolithic program, or even various software modules, software objects are provided with an interface which may be used by other programmers who may not be familiar with the internal workings of the software objects. Instead, they are provided with an interface which may take the form of certain defined datatypes, or of “public” functions, which they can access by providing known arguments or quantities, and they may expect a certain type of data according to the definition of the interface.
The interface may be implemented by means of datatypes meeting object or structure definitions both in the interface and the accessing program; the interface may also be accessed by means of “public” functions in the object of the interface. “Public” in this, the programming sense, means a function accessible to a later developer, but does not necessary imply that the interface definitions or functions will be published outside of the entity creating the interface code. The software objects may be encapsulated, i.e., it may be specified by the original author that they may not be modified by a programmer or developer who later uses the object. Just as the techniques of object oriented analysis, design and programming provide superior ways of dealing with the logical structure of software, so the techniques of component technology provide superior ways of dealing with the physical structure of software. A software component will ideally provide a well-defined, “guaranteed” interface which may be relied on by programmers; an implementation separated from the interface of which a programmer using the component may be ignorant; a physical implementation of the software that is separately releasable and versionable; and will be free from cyclic dependencies. This means that a component may not use, i.e. depend on another component, if that second component already depends directly or indirectly on the first component. These ideal characteristics of components provide for software that may have its functionality physically distributed among clients and servers across networks. The software may, in addition, have its functionality distributed across programming languages-providing interoperability between components implemented in different languages (C/C++, Java, Smalltalk, etc.).
An attendant benefit of this component architecture is that the software programming and maintenance task may be distributed—software may be divided into smaller pieces that can be built separately, but according to stable, common definitions assuring interoperability if the definitions are adhered to. This, in turn, provides more easily understood and maintained code. The cost of modifying the code is more easily estimated and controlled, should software changes be required. This in turn is due to the shortened incremental build times of components, because a change to the implementation of one component doesn't require rebuilding other components. The code is more easily reused by other projects, and standardized “off the shelf” development tools based on established components may be developed by various parties.